Tech for Growth project | ICICI Bank

Defining the product

Mission Statement

The mission statement for my product is to be a one-stop solution for entities of fitness ecosystem. It caters to fitness service providers by designing solutions for end-to end management of members, staff and potential members.

Ideal Customer Profiles

A fitness firm that:

1. Has reached at least medium scale of operations,
2. Has multiple programs to offer,
3. Is looking to manage firm's business and operations through a web service

JTBD

• Ability to track operations and staff productivity
• Improve overall user experience of the members. (At studio and outside studio pertaining to the fitness activities)
• Provide enough tracking mechanisms to onboard more members from leads
• Provide more data points to improve engagement of existing customers

Features

User settings & preferences: Broadly, the settings and preferences apply to members as well as staff, with options to set preferred time slots, nature of activities applicable (example, as instructor, what sessions can be provided vs as member, what sessions does member want to take), indicate or communicate lack of availability for a pre-planned session or requested slot. However, the settings have many more nuances for the service provider, where any staff can be mapped to multiple locations / facilities, specific programs and packages can be made available at only designated locations, tasks can be allocated to concerned staff with due date, priority and activity link (Activity link in this context pertains to booking call, SMS, consultation or session).

Calendar: This is a calendar specific to the fitness organization, wherein the slots or sessions would be synced for each trainer. The pre-decided slots will be part of the shared calendar between trainer and trainees. User can move the slot and change the trainer as per availability or even pre-book an activity specifying class type and timing with an option to choose or reserve instructor. The instructor can also update a pre-booked session, accept any request of pre-booking made by users, update one's availability and add new activity(ies) into the calendar.

Reminders & updates: These are applicable to members and staff, and work similar to push notifications. Automation rules can be configured by staff to send reminders for a scheduled session or a booked task in the calendar. Also, when an event is updated (example if a session gets moved to another slot or cancelled), this is intimated to all the involved parties through SMS or MMS modes.

Campaigns & communication: Apart from the above messages, there is option for members to initiate peer-to-peer communication with other members, including trainers. Campaigns operate similar to the above mentioned reminders, however this is applicable to existing or potential leads. Message clusters are configured depending on the stage of lead.

Attendance & trainer effectiveness tracking: Barcode scanning capture attendance of both trainer & members. Staff presence is tracked through check-in, check-out times. There is provision for staff to mark attendance for specific sessions in which case, the calendar will also get synced automatically.

Monitoring leads: Leads module captures data points regarding what is the source of lead, at what stage is it currently and what activities and automation need to be pursued further with each of them through task allocation window. Once successfully converted, the entity will be migrated to member profile.

Payment workflow: This includes invoice generation, facilitating payment cycles (waiver codes corresponding to user cluster; coupon codes, referral benefits if any; credit for the charges pertaining to communications, postal letters to be factored in before making the final payment), storing payment preferences, refunds related to cancellation and staff payouts. The invoices are categorised into unpaid and paid categories with details on due date and due amount. This will enable automation rules to be configured subject to status of payment.

Report generation: Broadly this covers sales related reports (example: gross sales, growth trajectory, net payment received, conversion ratio for leads, forecasted sales for next month, CTA for campaigns), member related reports (attendance, activation, cancellation, attrition, transfers, lifespan, re-instated members, referrals, check-ins), payment reports, performance and ratings of product and staff.

Technical Breakdown

Technical Stack

Core has integrations with multiple sub-systems to specifically handle a certain module or functionality. Calendar being one of its core features, seamless synchronisation between all the components & data binding seem to be prioritised, making Angular their preferred choice for front-end development in web. Also, the solution was primarily designed for web, & has chosen a mobile-optimised experience. With Angular, the development team can create applications that run across various platforms.

The experience chosen is mobile-optimised with selective functionality developed for mobile version. Majority of the features and functionality are for the service providers whose primary source of accessing the solution is via desktop. This was the only customer segment that the application started off with also (Meaning, there was no member or trainee module in the application).

Subsequently, modules for trainees to message, book and update slots got added. Out of these, the messaging functionality has a higher scope of usage in mobile and has been developed specifically for mobile. Cross-platform is the platform mode for mobile development & React Native is the technology used. This module still has limited functionalities and owing to lower scale of its usage, this seems like a good choice. Although the current functionality can probably be supported via hybrid platform as well, if improvement in UX and mobile adoption for staff is expected to increase in the longer run, then cross-platform or native is the better choice.

Design does not seem to be optimal. The layout and overview seems like too many things are packed onto a single screen and considering the number of functionalities crunched into a page, it is very likely that there are way too many network calls per page. The API framework used for network calls is RESTful across the application. There does not seem to be much scope for discoverability in any workflow anyway, and even if this is considered in the future development cycles, REST would be able to cater to this. Keeping a tight check on latency via choice of API architecture does not seem to be a good tradeoff.

There are multiple web-hook configurations as well. This is used to sync event or session details between Core and Connect, trigger reminder messages or intimate about any update to the scheduled events via Connect to intended members. The customer data is synced via Cron that runs on a daily once schedule.

The overall ClubReady web solution is currently in the form of two applications: Core & Connect. When there was a need to set up messaging and communication module, Connect was acquired and then 'ClubReady Connect' integrated with Core. Business logic for each of the application, including Core follows monolithic architecture. The server side is programmed in PHP Laravel. The choice of language seems justified, especially from the angle of relevance of queue systems & event broadcasting for Core.

All web interactions or user sessions are recorded, which will be used for log generation. These are expected to provide key inputs on user's journey to the developers at ClubReady as well as help in easy resolution of any technical issues faced. Logrocket is the tool used to auto-capture user interaction in the application.

The invoice generation is carried out inhouse and the module has integration with payment gateways to facilitate the online payment mode via cards. Payment preferences captured here are maintained in caching layer.

Broadly, data can be classified into 6 modules: user related data points (member, staff, leads), messages and communications sent out, recording of user interactions, metadata for messages and videos, payment related information & schedule specific values. All preferences & basic details about users are cached, with a daily once sync rate.

​

​

All the reports generated are also an outcome of the user, payments and messages modules. The data stored is processed to calculate the required data points and then visualizations projected to the clients. The dashboards are not interactive currently and the report generation activity follows a static structure.

Largely, the data has a structured form and SQL is used to store this data. Messages although initially stored in SQL are moved to AWS Open Search every 3 days. All the screen recordings captured are moved to Amazon S3. Devops is completely configured via AWS tools: Amazon RDS is used for database management & Elastic Beanstack is used for queuing and deploying the code and environment in AWS.

What to build?

Solution:

​Proposal is to build a referral workflow for the fitness firms. Currently, the lead module captures the source of lead and this includes referrals too. And one of the reports tracks referral conversion rate as well. However, apart from these two legs, there isn't any other journey for this.

Members will have option to invite any of their contacts to book a trial session: i.e., they should be able to initiate this first SMS from the mobile application with an option to add suggestion of one session and/or fitness instructor. The SMS will have a web URL, that will redirect customer to a UI. If there was a suggestion, then the same would be filtered and shown first. However, the referred person will be able to see categories of all activities at the fitness club. In the latter case, user can first choose a location or city and the categories of physical sessions will be sorted based on proximity & relevance, whereas online ones will be based on relevance. (Note: Relevance in this context is a function of popularity, i.e., the number of slots per week, the class booking ratio & attendance ratio) The referred entity will have option to express interest in any and further book a trial session. Confirmation SMS will be triggered to the user with a URL, which the entity can use to make any updates to the event if required. This event and entity will be stored in the lead module, from where staff can further configure any automation workflow to further trigger SMS or reminders.

Since the product has entered matured scaling stage, members who have attended even one session can generate the initial referral SMS. The benefits will be adjusted in the next payment cycle for member(s) (i.e., the initial member and subsequently if the entity becomes a member then them also), once the entity attends a trial session. Members should be able to track the stage of referral (Note: the various stages being if they have booked a trial session yet, if they have updated the booking to a later date, if they have booked and cancelled, if there is no response) and should be able to re-trigger SMS with suggestions of another session or instructor.

Journey

JTBD is to help each of the fitness client of ClubReady bring in more members through referral program. This journey will require:

• Updates in existing front-end of mobile and web application,
• Development of a standalone journey for referred user's UI mentioned above,
• Configuring API calls from this web page to support person to choose any session of choice, if the suggestion is not valid
• Introducing a calendar instance for the referral leads to book the trial session event,
• Syncing this event and details of referred user through web-hooks at Core & Connect for the staff to see this and action in the web app.
• Extending auto-capture to the actions of the referred entity, which will then form new logs.
• Storing additional data points in SQL DB for trial booking details, current stage, member who initiated the referral
• Factoring in these inputs into the existing referral report (i.e., count of such sessions booked, % of conversions, fitness session or instructor ranked in the order of members suggestion) which would be available in the web app.

Nuances and Trade-offs

The above mentioned workflow is a proposal for initial launch of this module. Considering the new module and the overall Core solution:

• Owing to lower scale of the mobile usage, the overall functionality is restricted in the mobile version as on date. The interactivity is quite low and the design has high inclination to a push style with low scope for discovery. Without making drastic changes to the overall structure, the above solution has been proposed. The mobile development has been proposed wherever it is non-negotiable. People are more likely to open and view the referral links received via SMS and hence the SMS trigger was proposed to mobile numbers. This meant having access to contacts and thereby member module is proposed for mobile version.
• Third party integrations are not proposed for this new module, since Tech-stack wise we do not have any major revisions or upgrades. In the overall app, except for payment module, there are no major 3rd party integrations. (Communication module was integrated into the overall architecture after acquiring as mentioned in the above sections). This may not have been an outcome of thorough evaluation and comparison between both the options.
• Caching has been factored into the overall application for user preferences, which has been covered in an above section. In the referral workflow, caching is not proposed since the nature of engagement is not sticky. Also, the search outputs would be dynamic, subject to the entity's inputs and interest and booking a slot would also require the latest status of calendar.
• Major limitation of overall Tech stack is the state of user interface. The features feel cluttered and there does not seem to be much of an ease in the workflow. Core application comes with significant maturity and the communication module was also in its early stage before it became Connect. There are still quite a few unused pre-developed modules in Connect, and especially because of that the business logic requires re-structuring and simplification. Having said that, the choice of platforms and tools of Core seems to be sound and chosen by keeping scale and optimality in mind. It should not require a lot of modification or addition in Tech stack to chart out a roadmap to increase engagement and scope of functionality in the coming years.

​

​

​

​

​

​